![]() |
![]() |
![]() |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
GPS System and Message Overviews Document Version: 5.9 Date: October 2, 2019
Copyright © 2009-2023 Jeppesen. All rights reserved.
Your use of the AIM Bookshelf and all supporting documentation is subject to a separate license agreement between you and Jeppesen, a copy of which is included in the zip file or can be obtained from Jeppesen.
The AIM Bookshelf is delivered "AS IS" without warranty of any kind and is not guaranteed to be free from errors or defects. You rely on the AIM Bookshelf at your own risk. No support for the AIM Bookshelf is implied through its publication. The AIM Bookshelf is intended solely for use as a reference and examples of interfaces to Jeppesen systems. Jeppesen may revise, update or cease publication at any time, without notice. Building to the specifications set forth in the AIM Bookshelf does not mean that your intended integration needs will be met or that an interface will function as documented. We recommend contacting Jeppesen directly to discuss professional services options with respect to production application integration and validation efforts.
Document Revision History The following revision history table reflects all substantive changes to this document since the previous release.
Table Of Contents
1 IntroductionThis document defines the interfaces which govern the interchange of data between a GPS system and other systems within an Airline Operation Center (AOC). Each AOC interface is represented by a message described in an associated XSD (XML Schema Definition). The XSD defines and enforces the required, optional, and conditional data that can be included in a message. 1.1 AudienceThe intended audience for this document includes existing and potential Jeppesen customers, integration partners, and personnel with roles associated with application architecture, application development, system testing, implementation, and application support within GPS. 1.2 ScopeThis document discusses the GPS messages currently supported by the Jeppesen Solution Integrator. Each message description includes the following:
Other data interfaces or formats not included in this document will be considered custom and not supported. 1.3 XML Schema/XSDThe XML schema for this ICD is published in the following file: GPS.xsd 2 Message SummaryTable 2-1 lists the messages that can be sent or handled by the application. The messages originated by this application (messages that begin with “GP”) are further discussed in Section 3 AOC Interface Messages. Table 2-1 Message Summary
3 AOC Interface MessagesThe following messages are processed by the GPS system. 3.1 GP001 - GPS RAIM Prediction3.1.1 Message OverviewRAIM (Receiver Autonomous Integrity Monitoring) is a technology that assesses the integrity of Global Positioning System (GPS) signals in a GPS receiver system. The RAIM Prediction report is used by a dispatcher or crew member to determine coverage of GPS systems for a given flight plan. FAA AC-90-100 dictates that all operators using RNAV as their primary navigation method must have a RAIM prediction report before departing. GPS devices utilize one of two algorithms for the RAIM prediction report. The GP001 message requires this algorithm be specified.
In addition to these algorithms, the ability to use barometric features is defined by the GPS receiver used within the aircraft. 3.1.1.1 Typical Message UsageThe GPS RAIM Prediction Report is typically requested by the dispatcher to validate GPS coverage for a specific flight plan. If there is acceptable coverage for a selected flight plan, then the dispatcher can file the flight plan; if the GPS coverage is unacceptable—either per the airline’s parameters or FAA requirements—then the dispatcher must select a different flight plan and then run the RAIM Prediction Report for that newly selected flight plan. Figure 1 . Typical GP001 Use in an AOC 3.1.1.2 Sample Periods and Minimum Duration OutagesThe RAIM Prediction Report calculates GPS coverage for points along the flight path according to the specified sample period. The sample period is the duration (in minutes) between each RAIM calculation. For example, if the sample period is set to one minute, then RAIM will calculate the GPS coverage for the expected location of the plane (position including altitude) along its flight path once every minute. Therefore, if the flight plan calls for a 60 minute flight, RAIM will perform 60 calculations for the plane’s position along that flight path. Reduce the sample period for a more precise analysis of the GPS coverage for a flight plan. Each airline can also specify their acceptable minimum duration outage. This number (in minutes) specifies the acceptable duration that an aircraft can be without GPS coverage. If a predicted outage has a duration of less than the minimum duration it is not included in the result set, if an outage has a duration equal to or longer than the minimum duration it is included in the result set. The purpose is to filter the results to contain only those outages of interest to the user [typical value would be 5 minutes]. For example, Jeppesen Airlines sets their minimum duration outage to five minutes for all flights. A flight plan is run for Flight 1234 from SFO to DEN, and then a RAIM Prediction Report is run against that flight plan. The RAIM calculates that there are two four-minute periods of GPS outage and one six-minute outage. The report ignores the two four-minute outages (because they are below the minimum duration outage threshold) and returns only the one six-minute outage. In this case, another flight plan is calculated for Flight 1234 to find a route without any outages greater than five minutes. NOTE: Although airlines can specify their own minimum duration outage, they must comply with current FAA regulations. 3.1.1.3 GPS RAIM Prediction Report OutputsThe dispatcher can select one or both of the following RAIM Prediction Reports with a single GP001 message:
Both of the above can be output as a graphical report (chart showing the GPS outages), a text report (detailed descriptions of GPS outages based on discrete fields) or both. The GP001 message provides maximum flexibility to allow Dispatch systems to request different RAIM Prediction Report parameters and output formats. 3.1.2 Message System FlowThis message interacts with the systems as shown in Figure 2. Figure 2. GP001 message system flow 3.1.3 Message DetailsThe following table provides details on the message version and includes links to the message’s technical specification.
3.2 GP002 - Station Group Discovery3.2.1 Message OverviewThis message is used to determine if there are any changes to RNP (Required Navigational Performance) station approach calculations for airports in the database. One system sends a GP002 (request) asking if there are any changes to the second system containing the RNP data. The second system then replies with the GP002 (response), indicating whether or not there are any changes. This message is typically sent at a regular period (for example, every three minutes) to identify changes soon after they appear in the RNP system. RELATED MESSAGES: If GP002 indicates RNP changes, then the GP003 message is used to gather the actual updates. 3.2.2 Message System FlowThis message interacts with the systems as shown in Figure 3. Figure 3. GP002 message system flow 3.2.3 Message DetailsThe following table provides details on the message version and includes links to the message’s technical specification.
3.3 GP003 - RNP Station Reports3.3.1 Message OverviewWhen the GP002 message identifies updates to the RNP stations approaches calculations, GP003 is sent to retrieve the actual updates. Similar to GP002, the requesting system sends the GP003 (request) message to the RNP system, who then responds with the GP003 (response) containing the actual RNP data. 3.3.2 Message System FlowThis message interacts with the systems as shown in Figure 4. Figure 4. GP003 message system flow 3.3.3 Message DetailsThe following table provides details on the message version and includes links to the message’s technical specification.
3.4 GP004 - Region Discovery3.4.1 Message OverviewThis message is used to determine if there are any changes to RNP (Required Navigational Performance) coverage within a certain region (defined as a polygon). One system sends a GP004 (request) to the second system containing the RNP data asking if there are any changes . The second system then replies with the GP004 (response), indicating whether or not there are any changes. This message is typically sent at a regular period (for example, every three minutes) to identify changes soon after they appear in the RNP system. 3.4.2 Message System FlowThis message interacts with the systems as shown in Figure 5. Figure 5. GP004 message system flow 3.4.3 Message DetailsThe following table provides details on the message version and includes links to the message’s technical specification.
3.5 GP005 - RNP Region Reports3.5.1 Message OverviewWhen the GP004 message identifies updates to the RNP coverage, GP005 is sent to retrieve the actual updates. Similar to GP004, the requesting system sends the GP005 (request) message to the RNP system, who then responds with the GP005 (response) containing the actual RNP data. 3.5.2 Message System FlowThis message interacts with the systems as shown in Figure 6. Figure 6. GP005 message system flow 3.5.3 Message DetailsThe following table provides details on the message version and includes links to the message’s technical specification.
|